linux: export getauxval when not compiling with libc#16977
Conversation
|
The CI failure: This happens on the tests which use dynamic linking - but specifying |
kcbanner
changed the title
kubkon
left a comment
kubkon
left a comment
There was a problem hiding this comment.
Looks good to my inexperienced eyes, but I do have a few questions that perhaps you can answer.
| /// This matches the libc getauxval function. | ||
| pub extern fn getauxval(index: usize) usize; | ||
| comptime { | ||
| @export(getauxvalImpl, .{ .name = "getauxval", .linkage = .Weak }); |
There was a problem hiding this comment.
As I understand, we are exporting it as weak because we expect it to be overriden by a different version in an exe/dso that has getauxval hooked up into startup routine? What if we're building an exe and link with a dso? Which version takes precedence then? Do I even understand the problem correctly here?
There was a problem hiding this comment.
As I understand, we are exporting it as weak because we expect it to be overriden by a different version in an exe/dso that has getauxval hooked up into startup routine?
Yes, exactly. The intention is that the version used is the one that references the elf_aux_maybe initialized by the startup code.
What if we're building an exe and link with a dso? Which version takes precedence then? Do I even understand the problem correctly here?
My assumption had been that the version in the exe would take precedence, but if this is not true in all cases then this solution won't be adequate.
|
Right now this pollutes every non-libC Zig Linux binary with the getauxv symbol & code, even if they never load libraries... This also means the compiler can't optimize away the ELF header parsing if nothing else uses it. Not a massive amount of bloat for real programs, but significant for the tiny "demo" binaries I like to make. |
3 participants
Closes #16975.
Before:
After:
The issue was caused by the version of
elf_aux_maybe(linux.zig) inlibnot being initialized by the startup code (since only the version in the exe existed), which caused the phdr lookup to fail (due to underflow when subtracting from zero).The panic within a panic trace:
However, this fix does pose a couple questions:
elf_aux_maybewill not be initialized and we're back to the original problem. Is this use case valid, though?std.process.getBaseAddresswhen called from a shared library linked to a C program. #16281